<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=Windows-1252">
<TITLE>Timetable validation & restrictions on timetabling</TITLE>
</HEAD>

<BODY BGCOLOR="#FFFFFF" TEXT="#000000">

<OBJECT TYPE="application/x-oleobject" CLASSID="clsid:1e2a7bd0-dab9-11d0-b93a-00c04fc99f9e">
	<PARAM NAME="Keyword" VALUE="Timetable validation">
	<PARAM NAME="Keyword" VALUE="Validation of timetables">
</OBJECT>

<P><B><A NAME="5.4"></A>5.4  Timetable validation & restrictions on timetabling</B></P>

<P>The 'Validate timetable' button in the timetable editor is available only when a railway is loaded and a timetable is open in the editor and saved to a file.  A timetable that is in course of development can't be validated until it has been saved (or saved under a different name using the 'Save timetable as...' button), because the validator works on the file.</P>

<P>Two sets of checks are carried out, the first for syntax, and the second for overall structure.  The first will reveal incorrect coding, the second will reveal incorrect timings such as a departure before an arrival, incorrect sequences such as arrival at Station A followed by departure from Station B, and incorrect service reference linkages etc.  Checking is quite comprehensive, so a timetable that is validated should load and operate correctly.</P>

<P>Timetable integrity is validated with respect to internal consistency, not with respect to railway layout.  It is the user's responsibility to make sure that a timetable is consistent with the railway.  For example if a train is to stop in sequence at A, B, C, D, but station layout is A, D, C, B, then when the train reaches D RailOS 'thinks' that stations B and C have been missed, so 'missed location' logs will be sent to the performance file.  As far as the timetable is then concerned B and C are no longer listed.  However the check for missed locations is only carried out as far as the next change-of-direction (cdt) if there is one.  This allows for services that stop at some locations on the way out and at the same or others on the way back.  For example, stations may be set out in sequence W, X, Y and Z, and a train stops at W and Z on the way out, then changes direction and stops at Y, X and W on the way back.  When it arrives at Z ready to return, it hasn't missed X and Y, so 'missed location' logs are not sent for these because they come after the change-of-direction.  This situation would normally be set up by changing service at Z (new headcode), but RailOS allows that same service to change direction and continue if required.</P>

<P>Note that a train that is timetabled to stop at the same station twice without a change of direction in between (running in a ring for example) will cause a validation error as the checker thinks that the second entry is a mistake.  To get round this restriction there must be a change of service (Fns - Sns combination) before the station is reached for the second time.</P>

<p><b>Timetabling restrictions</b></p>

<p>Because of programming constraints there are some restrictions in RailOS timetable structure that are not found in real life.  These have been kept to a minimum but if they occur an error message will indicate the nature of the restriction.  In almost all such cases, with a bit of thought, workarounds can be found that reflect real-life practice.  These restrictions are due to the validator needing to associate a location name with every event that takes place when a train is at a location.  All Fns events are named first, from a preceding arrival (where the location is named explicitly in the timetable) or from an Snt event that is at a location, then Sns events are named from the preceding Fns location.  Therefore an Fns that follows an Sns event can't be named because the Sns event hasn't yet been named.  After Fns and Sns events are named fsp and rsp events are named from a preceding arrival or from an Snt event that is at a location, and Sfs events named from the preceding fsp or rsp events.  Therefore an Fns event can't follow an Sfs event without a departure and arrival between them, and fsp and rsp events can't follow an Sfs event again without a departure and arrival between them.  These are the restrictions that are likely to be encountered in practice, but in almost all cases there will be workarounds available.</p>

<p>An example workaround is when a locomotive brings a train into a terminal station, drops off the carriages (by splitting the train into locomotive and unpowered stock), then runs round the stock to attach (join) at the other end to take the train back out of the station.  The validator requires that either the loco or the stock changes its service reference before the join, because a service can't split and then rejoin the same service reference.  Another restriction is that a train that splits off from another (begins with Sfs - starts from split) can't immediately change to a new service (i.e. can't end with Fns - finish and start a new service).  The way round this is to have the split-off train finish with Fjo - finish and join another train, and the original train change to a new service then have the split-off train rejoin it using jbo - joined by other train.  Therefore in the case of a run-around there are two possibilities:  (a) the loco splits off from the stock, runs around and rejoins the stock using Fjo, and the stock changes to a new service then rejoins the loco using jbo; and (b) the stock splits off from the loco and rejoins the loco using Fjo, and the loco changes to a new service, runs round the stock, then rejoins it using jbo.</p>

<P>See <A HREF="5.111w8h.htm">section 5.11</A> for some important aspects that will help to avoid errors.</P>

</BODY>
</HTML>
